Add reproject on table, and derive crs from geometry
#93
Conversation
|
hmm, is this necessary? GeometryOps already does this in That being said it only operates on the first geometry column. Maybe it should operate on all of them. But at some point I think it makes sense to centralize around GeometryOps for this, since GDAL reprojection is almost always slower than going through Proj... |
| function getcrs(table) | ||
| if GeoInterface.isfeaturecollection(table) | ||
| return GeoInterface.crs(table) | ||
| elseif first(DataAPI.metadatasupport(typeof(table))) | ||
| end | ||
| crs = geomcrs(table) | ||
| if !isnothing(crs) | ||
| return crs | ||
| end | ||
| if first(DataAPI.metadatasupport(typeof(table))) | ||
| crs = DataAPI.metadata(table, "GEOINTERFACE:crs", nothing) | ||
| if isnothing(crs) # fall back to searching for "crs" as a string | ||
| crs = DataAPI.metadata(table, "crs", nothing) | ||
| end | ||
| return crs | ||
| end | ||
| nothing | ||
| end |
There was a problem hiding this comment.
This would be great to upstream into GeoInterface, maybe if we make it a bit more generic to Tables.jl geometries?
There was a problem hiding this comment.
Yes, ideally as a package extension on DataAPI?
There was a problem hiding this comment.
DataAPI is already a dependency i think (but maybe that PR is still open
I wanted to extend GeometryOpsCore, as stated in the other issue. FWIW, I'm not sure if GO is faster than GDAL, as we need to extract the coordinates from GDAL, and GDAL itself uses PROJ (so their internal path might be faster than the Julia route?). I can imagine we specialize on the geometry type (especially once #92 is merged). edit: Before I introduce even more type piracy, I expect to introduce a spatial vector type and a specific geodataframe type after #92. |
|
I'm pretty sure GO is faster than GDAL for this, having written both functions. First calling Proj.jl directly like GO does has so little overhead, and second converting geometries to GDAL objects as an intermediate is relatively expensive. If you have GDAL geoms already GO is probably still competitive. But ArchGDAL doing more is fine with me anyway. (But personally I don't contribute much here anymore, GDAL geoms have so many problems and complexity. Focussing efforts may be worthwhile given our community size) |
|
I didn't mean to cause offense 😅 GDAL will eventually be the fallback driver, anything on the Julia side will indeed be much faster with GO. And I fully understand focusing more on native stuff. |
|
Not at all offended! Just thinking about allocation of effort |
Like the previous releases, this exported
reprojectstill clashes on with GeometryOps, but at least operates on a table now, instead of on a column only (and forgetting to set the crs metadata on the table). A new breaking release will have to change this.This also enables writing using the crs of the (first) geometry in the table, as requested by @alex-s-gardner.
Also drops the GeoJSON export, as pointed out by @asinghvi17.